fix(codex): detect status from rendered screen - #579
Conversation
There was a problem hiding this comment.
Pull request overview
This pull request fixes Codex status detection getting stuck in PROCESSING by opting CodexProvider into CAO’s existing pyte rendered-screen (composited viewport) status path, so detection runs against what’s currently visible instead of the append-only tmux pipe-pane stream that can retain erased spinner frames.
Changes:
- Enable rendered-screen status detection for
CodexProviderviasupports_screen_detection = True. - Add
CodexProvider.get_status_from_screen()that trims pyte’s padded rows and reuses the existing line-oriented detector on the rendered viewport. - Add unit regression tests covering erased MCP startup spinners, active spinners, and completed turns on the rendered screen.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/cli_agent_orchestrator/providers/codex.py | Opt Codex into pyte screen detection and implement get_status_from_screen() to avoid stale in-place redraw frames pinning PROCESSING. |
| test/providers/test_codex_provider_unit.py | Add regression tests validating correct status behavior on composited screen output for MCP startup spinners and completed turns. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #579 +/- ##
=======================================
Coverage ? 91.15%
=======================================
Files ? 181
Lines ? 23788
Branches ? 0
=======================================
Hits ? 21683
Misses ? 2105
Partials ? 0
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
b38cb24 to
f7a2f84
Compare
haofeif
left a comment
haofeif
left a comment
There was a problem hiding this comment.
One blocking status-correctness issue found.
Codex redraws its TUI in place, so the append-only pipe-pane stream can retain erased MCP startup frames and leave status stuck at PROCESSING after the visible terminal is ready. Opt Codex into the existing pyte-composited status path and reuse its line-oriented detector on the live viewport. Add regression coverage for an erased startup spinner, an active spinner, and a completed turn. Refs awslabs#537.
f7a2f84 to
e713dbf
Compare
Summary
CodexProviderinto CAO's existing pyte-composited status pathProblem
Codex redraws its inline TUI in place. The raw
tmux pipe-panestream retains frames that were later erased from the visible terminal, so an MCP startup spinner can pin CAO atPROCESSINGeven after Codex is visibly ready. This is the Codex-specific gap described in #537 after the rendered-screen framework shipped in #293.The change enables that existing framework for Codex and reuses the provider's line-oriented status detector on blank-trimmed viewport rows. The open generic recovery work in #558 is complementary; this fixes the provider at the normal detection path without waiting for a capture-pane fallback.
Validation
uv run --frozen pytest test/providers/test_codex_provider_unit.py -q— 177 passed, 3 skippeduv run --frozen pytest test/services/test_status_monitor.py -q— 30 passedgit diff --check origin/main...HEADpassesRelated: #537, #293, #558.